Human beings are visual creatures by nature, and it should come as no surprise that the graphical user interface (GUI) has become the preferred method through which users have chosen to interact with their computers. Current GUIs, such as those in the MICROSOFT WINDOWS (™) line of products, display a number of graphical panels, often referred to as “windows,” through which users may interact with various computer applications.
To illustrate, FIG. 7a depicts an example GUI in which a display area 701 contains a number of graphical panels 702a, b, that represent two applications operating on the system. These applications may be, for example, a word processing program 702a (for example, MICROSOFT WORD(™)) and a drawing creation program (for example, MICROSOFT VISIO (™)) 702b. The various panels 702 are overlaid atop one another (if they overlap one another), in what is often referred to as the “z-order” of panels (the hierarchy of panels that determines which panel is on top when two or more panels overlap), where the topmost panel in the z-order receives the so-called “input focus.” This input focus identifies the application whose panel is currently being used by the user, and helps the computer operating system identify the application that should receive certain inputs to the system. For example, if the user presses keys on a keyboard, the input focus identifies the application that will receive and process those key presses.
The system assigns the input focus according to the user's commands. For example, the GUI often includes an onscreen pointer 703, which may be moved about the display area 701 by the user with an input device, such as a trackball or mouse (not shown). By positioning the pointer 703 over a particular panel 702b, and pressing or “clicking” the left mouse button, the user can determine which panel is to receive the input focus. In FIG. 7b, panel 702a currently has the input focus, and is at the top of the z-order (it appears above other panels). The user has positioned the pointer 703 over panel 702b, and after pressing the designated key (e.g., entering a mouse click), panel 702b is given the input focus and is brought to the foreground, resulting in the display shown in FIG. 7c. Subsequently, user inputs to the computer's keyboard will be forwarded to the application corresponding to panel 702b, as opposed to panel 702a. 
The mouse click that selects panel 702b is also reported by the operating system to the application corresponding to panel 702a, which in turn prepares to lose the input focus. In preparing to lose input focus, the application corresponding to panel 702a prepares to be placed in the background, and closes any “transient” user interface (UI) elements, such as menus.
While the existing GUI described generally above is suitable for users of many typical personal computers, a new generation of computing devices has introduced a unique perspective, and problem. The computers in this new generation can be operated without the traditional keyboard and/or mouse to which we have become accustomed. Examples include the tablet, or pen-based, line of computer products introduced by Microsoft Corp.
Since these pen-based computing devices may not always include a separate keyboard, alternative approaches to providing user inputs will be needed. However, existing options for providing user inputs, without a keyboard, are not fully adequate. One existing option is the Accessibility Keyboard offered by the MICROSOFT WINDOWS (™) operating system. The Accessibility Keyboard appears as a panel resembling the traditional keyboard with the “qwerty” arrangement of character keys. After opening the Accessibility Keyboard, the user is prompted to select the application panel that is to have the input focus (by “mouse-clicking” on it), and subsequent selections of the displayed character keys on the Accessibility Keyboard will cause the selected characters to be sent to the designated application panel.
The Accessibility Keyboard is not, however, a complete replacement for the keyboard. For example, mouse clicking on a key in the Accessibility Keyboard causes transient UI elements (e.g., menus) in other application panels to close. This occurs because the Accessibility Keyboard is implemented as if it were another application panel, and is treated as such. Accordingly, keyboard interaction with such transient UI elements (e.g., selecting a menu item by pressing a key) is not possible using the Accessibility Keyboard (e.g., the menus disappear, rather than respond to the character). Accordingly, there is a need for an improved approach to managing user inputs and Bordering of application panels.